介绍
这一系列文章, 旨在描述面对一个从零开始的 B(C)/S 应用的时候, 如何去搭建一个业务无关的平台, 承载上层应用流量. 这里要强调这个平台的几个特点:
- 业务无关性: 无论业务的形态如何, 均可以在此架构之上运行, 这里可能会面临若干情况, 如无状态服务, 长连接服务等, 后续会根据场景运行描述, 但是这些场景可以看作是一个有限集.
- 可扩展性: 这里的扩展性特指两个方面, 一是业务的扩展, 二是流量的增加, 这两者对于任何一个平台而言, 都是要着重考虑的.
业务根据不同的指标, 可以分为若干类, 这里期望通过两种指标来描述这一系列文章想要覆盖的场景, 以说明业务无关性
:
- 根据状态: 分为
无状态
服务和有状态
服务 - 根据实时性: 分为
异步
与实时
应用
这两个指标可以任意组合, 但是最常用的组合应该是属于无状态-异步
及有状态-实时
应用了, 但是通常也会有无状态-实时
应用存在, 比如对于一个博客系统, 可以认为其是一个无状态-异步
应用, 而一个一对一的聊天应用, 则可以看作是无状态-实时
应用, 而大多数在线游戏, 则是有状态-实时
应用, 需要注意的是, 业务场景不会严格按照上述概念进行区分, 最终大多都会形成一个无状态
与有状态
, 异步
与实时
共存的状态.
微服务化是满足扩展性的基石, 这也是文章会首先描述的一个整体性架构, 单机应用会在后期引发若干难以解决的问题, 所以这是一开始就需要考虑到的事情.
文章会主要描述以下几个部分:
- 应用分支与模块化
- 持续集成
- 有状态的长连接应用扩展性设计
- Web 端构建与模块化
微服务的存在, 致使应用分散在若干服务器集群中, 如何有效管理集群是一个比较庞大的话题, 但是目前业界已经有了比较一致的具有完备性的技术方案, 如k8s, rancher等, 特别是云服务商的出现, 掩盖了硬件管理这个最复杂的环节, 所以这里不会去讨论关于容器编排相关的话题.
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。